Processing and Optimizing Travel Insurance Transactions

ABSTRACT

A method and system are provided for processing communications between travel service providers and travel insurers where travel service providers use different messaging formats. A travel service provider transmits itinerary data to a travel insurer in one messaging format. The travel insurer may then convert the itinerary data into a format compatible with the travel insurer&#39;s system and determine an optimal policy choice based on the itinerary data. The travel insurer may then transmit this choice to the travel service provider in the travel service provider&#39;s preferred messaging format, and the travel service provider offers the product to the consumer through the travel service provider&#39;s interface.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation of U.S. patent applicationSer. No. 13/231,535, filed on Sep. 13, 2011, which will issue as U.S.Pat. No. 8,577,767 on Nov. 5, 2013. This patent application claims thebenefit of U.S. Provisional Patent Application No. 61/382,418, filed onSep. 13, 2010.

FIELD

The present invention relates generally to data processing and relatesmore particularly to processing communications between travel serviceproviders and travel insurers.

BACKGROUND

Retail sellers often partner with other types of retail sellers toprovide consumers with a convenient forum from which they can havemultiple product needs met. For example, travel insurance companiesoften partner with travel service providers (airlines, hotels, on-linetravel agencies, etc.) for the integration of travel insurance into the“booking path” of the travel purchase. When a consumer purchases anairline ticket on an airline's website, an offer is made to the consumerfor travel insurance. If the offer is accepted, a policy is issued. Inthis example, the airline's booking system interacts with the travelinsurer's system, typically via XML messaging, to quote and bind theinsurance policy as part of a seamless consumer experience.

The travel insurer may require travel service providers (e.g., theairline) to undergo an extensive and time-consuming integration processwhereby they “code to” the travel insurer's XML specification.Additionally, the travel service providers are required to develop thelogic on their systems whereby they communicate to the travel insurerwhich product will be sold on a particular transaction to a particularconsumer. The travel insurer may provide the business logic for theseproduct choices, but the burden typically falls on the travel serviceprovider to develop the technical logic to support it.

For example, an airline or other travel service provider's website mustdetermine which product is appropriate for the consumer and then requesta quote using the travel insurer's proprietary XML specification.Because the business logic is implemented on the travel serviceprovider's website, the travel insurer simply responds by providing aquote to the travel service provider, rather than verifying the travelservice provider's product choice or providing alternative or moreoptimal options. This arrangement between the travel service providerand the travel insurer limits the capability of the travel insurer toprovide flexible and up-to-date product choices available to theconsumers. This arrangement can also result in errors due to the lack ofverification by the travel insurer.

It will be appreciated that the inventors have created the above body ofinformation for the convenience of the reader. The foregoing is adiscussion of problems discovered and/or appreciated by the inventors,and is not an attempt to review or catalog the prior art.

SUMMARY

The described invention allows for the processing of different dataformats that contains the business data needed to sell a product withoutrequiring a partner to code to a specific standard. A preferredembodiment of the invention has applicability in quoting and bindingtravel insurance. A travel service provider may send relevant itinerarydata to the travel insurer utilizing the travel service provider'spre-existing or preferred format, and the travel insurer determineswhich product is appropriate for the itinerary and responds to thetravel service provider in the travel service provider's pre-existing orpreferred format. In contrast to conventional systems, travel serviceproviders are not restricted to using a particular XML format specifiedby the travel insurers, so the travel service providers are free to usewhichever data format is more convenient to them (including XML, HTML,or simple text delimited files). Furthermore, an optimal policydetermination is performed at the travel insurer's system to allow thetravel insurer to provide better and more up-to-date policy optionsbased on the itinerary data, as well as allowing the travel insurer toverify that the correct policy option or options are being offered tothe consumer based on the itinerary data.

In a general embodiment, a partner sends transaction data to a seller inthe partner's preferred format, and if the partner's preferred format isincompatible with the seller's preferred format, the data needed isextracted and converted to the seller's preferred format by an XMLprocessor. The particular conversion code for each partner's preferredformat may be advantageously loaded into the XML processor's memorycache for increased speed and security.

The seller may then apply the seller's product selection logic to thetransaction data to determine an optimal product or products based onthe transaction data. Because the product selection logic is beingimplemented on the seller's system, the seller is able to formulate avariety of options suited specifically to a particular consumer's needs.The seller can verify that the product selected is appropriate for theconsumer, the seller can provide alternative product choices, and theseller has flexibility in freely changing its product selectionalgorithms. Thus, the seller can account for additionalconsumer-specific variables and rapidly adapt to changing marketconditions.

After determining an optimal product or products, the seller's systemmay utilize an XML processor or other appropriate processors to convertthe optimal product or products data into the partner's preferredformat, and the message may then be transmitted to the partner. Thepartner displays the product choice or choices on its website, and theconsumer receives an optimal product offer or offers based on theseller's recommendations. The seller may additionally includeadvertisements or promotional material in combination with the productoffer or offers displayed on the partner's website.

In a preferred embodiment described with further detail herein, theseller is a travel insurer and the partner is a travel service provider,and the travel insurer's product offerings are integrated into theinterface that the travel service provider presents to consumerspurchasing the travel service provider's products.

As will be appreciated by the teachings herein, the present inventionallows partners to utilize whichever format for data storage andtransmission that they prefer, as well as allowing sellers to offeroptimized product choices and change product options with greatlyreduced technical support from partners. Other objects and advantages ofthe invention will become apparent upon reading the following detaileddescription and upon reference to the drawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

FIG. 1 is a diagram illustrating the components of a travel insurer'sdata processing system in one exemplary embodiment;

FIG. 2 is a flowchart illustrating the processing of itinerary datareceived from a travel service provider at a travel insurer system inone exemplary embodiment; and

FIG. 3 is a flowchart illustrating the processing a customer responsereceived from a travel service provider at a travel insurer system inone exemplary embodiment.

DETAILED DESCRIPTION

While the invention is described below in the context of a preferredembodiment involving a travel insurer as a “seller” and a travel serviceprovider as a “partner,” it will be appreciated that the inventiveprinciples disclosed with respect to the preferred embodiment are morebroadly applicable to other seller-partner relationships.

FIG. 1 provides an exemplary system architecture 100 of a travelinsurer's system and its connection to a travel service provider'ssystem. A computer or server 102 of the travel service provider's systemis connected to a network 110 (e.g., the Internet). It will beappreciated that the travel service provider's system may be morecomplex and include more components (e.g. databases, applicationservers, firewalls, etc.), but for simplicity of illustration only acomputer or server 102 is depicted.

The travel insurer's system 120 is also connected to the network 110 andprotected by a firewall 121. Messages received through the network 110are processed by a conventional load balancer 122 (for distributingworkload corresponding to entities accessing the travel insurer'ssystem) and one or more XML processors 123, which parse receivedmessages to extract data and re-format the messages (to a formatcompatible with the travel insurer's proprietary rating and issuanceengine residing on application servers 124) if needed. Preferably, apool of multiple XML processors 123 may be used. In one embodiment, theXML processors may be DataPower XI50s manufactured by IBM, of Armonk,N.Y.

The travel insurer's system 120 further includes application servers124, through which the travel insurer's proprietary rating and issuanceengine may process message data to determine an appropriate policy.These application servers 124 may access data from database servers 126within the travel insurer's system 120, and the connection between theapplication servers 124 and the database servers 126 may be protected byanother firewall 125.

It will be appreciated the travel insurer's system 120 need not beimplemented in the manner depicted and that one of ordinary skill in theart would be able to vary the system design and still practice theinventive principles described herein. For example, various componentsof the travel insurer's system 120 may be interconnected withoutfirewalls, or the travel insurer's system may additionally include a webserver (depending on how the travel service provider's user interface isconfigured). It will further be appreciated that, in other embodiments,the various components described herein (e.g. the load balancers, XMLprocessors, and application servers) may be implemented by other typesof hardware, such as a general computing unit with appropriateprogramming.

It will further be appreciated by those of skill in the art that theexecution of the various machine-implemented processes and stepsdescribed herein may occur via the computerized execution ofcomputer-executable instructions stored on a tangible computer-readablemedium, e.g., RAM, ROM, PROM, volatile, nonvolatile, or other electronicmemory mechanism. Thus, for example, the operations performed by thetravel insurer's proprietary rating and issuance engine may be carriedout according to instructions or applications stored at the applicationservers 124.

Given the exemplary system architecture depicted by FIG. 1, a generalprocess 200 for receiving and processing itinerary data from a travelservice provider (TSP) at the travel insurer's system 120 is depicted byFIG. 2. In one embodiment, the travel insurer's system 120 receivesitinerary data corresponding to one or more consumers from a travelservice provider's system 101, and the itinerary data is formatted usingthe travel service provider's preferred format, which may be, forexample, XML, HTML, or simple delimited text (201). A component of thetravel insurer's system 120, such as the load balancer 122, XMLprocessors 123, or application servers 124, then determines whether theitinerary data is in a format that is compatible with the travelinsurer's rating and issuance engine (203). If it is not compatible, theXML processors 123 convert the received itinerary data into a formatthat is compatible with the travel insurer's rating and issuance engine(205), and the rating and issuance engine, implemented on theapplications servers 125 and accessing information from database servers127, determines one or more optimal policy options based on theitinerary data (207). If the received itinerary data is alreadycompatible with the travel insurer's rating and issuance engine, noconversion is necessary.

If the optimal policy data determined by the travel insurer's rating andissuance engine is not in a format compatible with the travel serviceprovider's system 101 (209), the optimal policy data is converted into aformat that is compatible with the travel service provider's system 101(211). The reformatted optimal policy data is then transmitted to thetravel service provider's system 101 for presentation to a consumerusing the travel service provider's system 101 (213). If the optimalpolicy data determined by the travel insurer's rating and issuanceengine is already in a format compatible with the travel serviceprovider's system 101 (209), no conversion is necessary beforetransmission to the travel service provider's system 101 (213). In apreferred embodiment, the offer to purchase travel insurance ispresented to the consumer through the travel service provider'sinterface in order to integrate the purchase of travel insurance withthe consumer's purchase of the travel services provided by the travelservice provider.

It will be appreciated that the determination of one or more optimalpolicy options by the travel insurer's rating and issuance engine may bebased on parameters including, but not limited to, the itinerary type(one way or round trip), the type of consumer (individual or multipletravelers), the trip duration, the category of destination, the tripcost (insured or policy level), the consumer's frequent flier status,and the type of package (air only or package deal). To perform thedetermination of the one or more optimal policy options, the rating andissuance engine on the application servers may query the database forunderwriting data and risk factor data such as itinerary-specific (e.g.,based on date, length of trip, region(s) being visited, etc.) costsrelating to lost luggage, medical expenses, and/or trip cancellations.The rating and issuance engine then applies one or more policycalculation algorithms to the itinerary data and risk factor data togenerate optimal policy data, which is transmitted to the travel serviceprovider and may include parameters such as plan choice(s), price(s) andcoverage(s). It will further be appreciated that more than one optimalpolicy option may be included in the optimal policy data and transmittedto the travel service provider's system 101 for presentation to theconsumer. For example, it may be advantageous to provide the consumerwith multiple travel insurance options based on their itinerary data inthe event that one or the other is more appealing to the consumer (e.g.,a less expensive plan including only cancellation coverage and a moreexpensive plan including coverage for both medical expenses andcancellation). In addition, the system and method of an embodiment ofthe invention may use a consumer-indicated preference or factor to beoptimized to determine an appropriate policy to be quoted (e.g., theconsumer may indicate that he or she wants comprehensive medicalcoverage but only minimal cancellation and lost luggage coverage).

In a further embodiment, advertisements and/or promotions may betransmitted to the travel service provider's system 101 for presentationto the consumer in addition to the one or more optimal policy optionsand/or prices (215). Such advertisements and/or promotions may bespecifically targeted to the consumer based on the itinerary data. Forexample, these advertisements may stress the need for insurance based onthe consumer's travel plans (“Protect yourselves from travel delayscaused by the holiday rush!”) or promote special discounted rates forspecific types of consumers (“Get an additional 10% Off! Exclusively forour Gold Members”). To accomplish this variation, application servers124 work in conjunction with database servers 126 to identify potentialinsurable risks, special circumstances, or other considerations. Forexample, if the itinerary data indicates that the consumer is going totravel to a hurricane-prone area during hurricane-prone season, theratings and issuance engine, working with the database servers 126, mayidentify that the risk for cancellation and/or medical expenses isespecially high and automatically generate corresponding advertisementsand optimal policy options taking those considerations into account.

Turning now to FIG. 3, in a preferred embodiment, a consumer may respondto the travel insurer's offer to sell a policy through the travelservice provider's interface (301). This response may indicate whetherthe consumer wishes to purchase the policy or not, and, in the eventthat the consumer wishes to purchase the policy, may further providepayment information (such as desired payment method and any necessarydetails). It will be appreciated that a lack of response for apredeteimined length of time (e.g. a timeout) may also indicate to thetravel insurer system 120 that the consumer does not wish to purchasethe policy. It will further be appreciated that other methods ofresponding to the offer may be utilized as well, such as, for example,providing a link to the consumer to access a travel insurer's webinterface directly.

The travel insurer's system 120 may determine whether data correspondingto a consumer response is in a format compatible with the travelinsurer's system 120 (303), and if it is not, may use one or more XMLprocessors 123 to convert the consumer response data into a formatcompatible with the travel insurer's system 120 (305). The applicationservers 124 may then process the consumer response data (307), which mayinclude processing the payment information (e.g. charging a credit cardusing credit card information provided by the consumer) and storingtransaction information at the database servers 126 (e.g. storingtransaction details or logging successful and unsuccessful policy offersor promotion offers). If the consumer response data was already in aformat compatible with the travel insurer's system 120 to begin with, noconversion may be necessary.

It will be appreciated that further communications may take placebetween the travel insurer system 120 and the travel service providersystem 101. For example, the travel insurer system 120 may transmit atransaction confirmation (e.g. including a policy number, paymentdetails, a message stating that the transaction was completed, etc.)back to the travel service provider system 101, performing formatconversion if necessary according to the procedures described above.

In order to transform a message from a travel service provider'spreferred format that is not compatible with the travel insurer'sproprietary rating and issuance engine into a format that is compatiblewith the travel insurer's proprietary rating and issuance engine, thetravel insurer may first verify that the travel service provider iscapturing the data that the travel insurer desires from the consumer.This may be performed by, for example, giving the travel serviceprovider a checklist as depicted in Table 1 below to ensure that dataused by the rating and issuance engine is being collected. It will beappreciated that Table 1 is merely exemplary and that more or less (ordifferent) data fields may be used.

TABLE 1 Data Collection Checklist CUSTOMER INFORMATION Customer LastName Customer First Name Customer Address Phone number email Country ofResidence Date of Birth Age Passenger Type (e.g.,Infant/Child/Adult/Senior) Customer Status (e.g., FF level - gold,platinum, etc.) Number of insureds/passengers on trip Customer ID (e.g.,Passport number) TRIP INFORMATION One Way/RoundTrip Indicator Origin(IATA airport code) Trip Begin Date Trip End Date Destination (IATAairport code) - (must be Furthest Destination) PNR/Record Locator (e.g.,ABC123) Trip Cost by Individual Payment Details (Cash, Credit Card,Miles . . . etc) If yes, please provide details Class of Service(First/Business/Coach) Fare Basis Code (e.g., YM, K14NYC) Booking Classof Service (e.g, F, Y, K, Q, K, N, X) Carrier/Provider Name (e.g.,United, American, NCL, Marriott) Airline Only versus Package IndicatorTotal Trip CostIf not all the data desired by the travel insurer is being collected,the travel service provider may be asked to adjust their interface so asto collect that data, or the travel insurer may modify its rating andissuance engine to work with the data presently collected for thattravel service provider in particular (or some combination thereof).

Assuming the travel service provider's data is collected in a messagingformat that is not compatible with the travel insurer's rating andissuance engine, the travel insurer may then map the data in the travelservice provider's format to corresponding data fields in the formatcompatible with the rating and issuance engine (e.g. identifying where acustomer's name is, where a customer address is, and where tripinformation is in the travel service provider's format). For example, inone embodiment, assume that the travel service provider uses an XMLmessage format (not compatible with the travel insurer's rating andissuance engine) and that a sample data record corresponding to acustomer's itinerary is provided by Table 2 below.

TABLE 2 Sample XML Message <?xml version=“1.0”?> <flight><customer_info> <first_name>John</first_name> <last_name>Doe</last_name><address>123 123rd Street, Los Angeles, CA 12345</address><phone>123-456-7890</phone> <email>john_doe@hotmail.com</email><country>USA</country> <date_of_birth>01.01.1978</date_of_birth><age>32</age> <type>Adult</type> <status>Platinum</status><number_insured>1</number_insured> <passport>123456789</passport></customer_info> <trip_data> <provider>XYZ Airlines</provider><round_trip>Yes</round_trip> <origin>SYD</origin><departure_date>08.26.2010</departure_date><return_date>09.05.2010</return_date> <destination>LAX</destination><flight_no>815</flight_no> <payment>Cash</payment><fare_basis>YM</fare_basis> <booking_class>F</booking_class><package>Yes</package> </trip_data> </flight>

A mapping code may be created using commercially available XMLprocessing tools such as the Altova MapForce data mapping tool and theAltova XMLSpy XML editor (developed by Altova of Beverly, Mass.) and maybe implemented in the memory cache of the XML processor. UsingeXtensible Stylesheet Language Transformations (XSLT), the travelservice provider's message containing the desired consumer data in thetravel service provider's preferred messaging format is manipulated togenerate a new message in a format compatible with the travel insurer'srating and issuance engine. It will be appreciated that a differentmapping may be used for each unique data messaging format used by aplurality of providers. One example illustrating an excerpt of severallines of mapping code used to transform the travel service provider'spreferred XML format to a format compatible with the travel insurer'srating and issuance engine is given by Table 3 below.

TABLE 3 Sample Mapping Code <?xml version=“1.0” encoding=“UTF-8”?> <!--This file was generated by Altova MapForce 2009sp1 Refer to the AltovaMapForce Documentation for further details.http://www.altova.com/mapforce --> <xsl:stylesheet version=“1.0”xmlns:xsl=“http://www.w3.org/1999/XSL/Transform”xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”xmlns:xs=“http://www.w3.org/2001/XMLSchema” exclude-result-prefixes=“xsxsi xsl”> <xsl:output method=“xml” encoding=“UTF-8” indent=“yes”/><xsl:template match=“/”> <TINS_XML_DATA> <xsl:attributename=“xsi:noNamespaceSchemaLocation”> <xsl:value-ofselect=‘“C:/Datapower/DA8DB2~1/StandardOffering/WaatsLite/Group1Input.xsd’”/></xsl:attribute> <xsl:variable name=“var1_instance” select=“.”/><Segment> <TransactionType> <xsl:copy-ofselect=“$var1_instance/TravelGuardInsuranceRQ/Transaction/TransactionCode”/></TransactionType> <TransactionId> <xsl:copy-ofselect=“$var1_instance/TravelGuardInsuranceRQ/Transaction/TransactionCode”/></TransactionType>

The message generated by the XML processor in the format that iscompatible with the travel insurer's rating and issuance engine willthen be processed by the rating and issuance engine. An exemplary set ofdata parameters that may be used by a rating and issuance engine in oneembodiment is given by Table 4 below.

TABLE 4 Sample Data Parameters Used by Rating and Issuance Engine DataParameters Sample Values GDS_CD AAA ORIGIN_IATA_CNTRY_CD 41ORIGIN_IATA_AIRPORT_CD ALL FREQUENT_FLYER_STATUS NONE DEST_CONTINENT_CDAS DEST_IATA_CNTRY_CD 41 DEST_IATA_AIRPORT_CD ALL TRIP_TYPE ALLISO_CURRENCY_CD ALL WAATS_IATA_AGENCY_CD 99999999 WAATS_AGENCY_PCC_CD99999 WAATS_PRODUCT_CD 20971 WAATS_PLAN_CD ONE WAATS_BENEFIT_CD 0RECORD_EFF_DT 6/14/2010 11:05:32 AM RECORD_EXP_DT 6/14/2030 11:05:32 AMSOURCE_SYSTEM_ID WT USERID_CD WAATS TIMESTAMP 9/2/2010 10:33:15 AM

Having received an XML message corresponding to itinerary data in aformat compatible with the rating and issuance engine containing thedata parameters used by the rating and issuance engine, the rating andissuance engine processes the data and outputs a message correspondingto an optimal policy or policies based on the itinerary data. An exampleof the policy data output by the rating and issuance engine in an XMLformat compatible with the rating and issuance engine is given in Table5 below.

TABLE 5 Sample Policy Output<TINS_XML_DATA><Header><ErrorCode>0</ErrorCode><ErrorMessage>OK</ErrorMessage><Version>1.0</Version><SourceId>AUS</SourceId><MessageId>6AUSq3caYz8DBnw0nS2O9Em735K</MessageId></Header><Segment><IgnoreFg></IgnoreFg><ErrorCode>0</ErrorCode><ErrorMessage></ErrorMessage><TransactionType>NSell</TransactionType><TransactionId></TransactionId><PolicyIn><GDSCode>AUS</GDSCode><AgencyPCC>CallCentre</AgencyPCC><AgencyCode>60000089</AgencyCode><IATACntryCd>6</IATACntryCd><TransactionType>NSell</TransactionType><GDSProductCode>020960</GDSProductCode><InceptionDate>06/03/201012:00:00 AM</InceptionDate><ExpirationDate>06/10/2010 11:59:00PM</ExpirationDate><PaymentType>0</PaymentType><TotalNumberOfInsureds>1</TotalNumberOfInsureds><Address></Address><PolicyType>0</PolicyType><GeneralPurpose2>WebSiteUser</GeneralPurpose2><TransactionApplDate>10/27/200901:33:43PM</TransactionApplDate><InsuranceType>IND</InsuranceType><TransactionEffDate>06/03/2010 12:00:00AM</TransactionEffDate><TransactionExpDate>06/l0/2010 11:59:00PM</TransactionExpDate>

Subsequently, as described above, this policy output may be convertedback to a format preferred by the travel service provider if necessary,and further communications between the travel service provider andtravel insurer may take place based on the user's response to the travelinsurance offer.

Thus, it will be appreciated that a new and useful method and system forsellers to provide flexible product options to consumers integrated intopartners' sites while requiring minimal technical integration effort bythe partners has been invented. However, it will also be appreciatedthat the disclosed embodiments are merely examples, and that thedescribed principles are more widely applicable. All references,including publications, patent applications, and patents, cited hereinare hereby incorporated by reference to the same extent as if eachreference were individually and specifically indicated to beincorporated by reference and were set forth in its entirety herein.

The use of the terms “a” and “an” and “the” and similar referents in thecontext of describing the invention (especially in the context of thefollowing claims) are to be construed to cover both the singular and theplural, unless otherwise indicated herein or clearly contradicted bycontext. The terms “comprising,” “having,” “including,” and “containing”are to be construed as open-ended terms (i.e., meaning “including, butnot limited to,”) unless otherwise noted. Recitation of ranges of valuesherein are merely intended to serve as a shorthand method of referringindividually to each separate value falling within the range, unlessotherwise indicated herein, and each separate value is incorporated intothe specification as if it were individually recited herein. All methodsdescribed herein can be performed in any suitable order unless otherwiseindicated herein or otherwise clearly contradicted by context. The useof any and all examples, or exemplary language (e.g., “such as”)provided herein, is intended merely to better illuminate the inventionand does not pose a limitation on the scope of the invention unlessotherwise claimed. No language in the specification should be construedas indicating any non-claimed element as essential to the practice ofthe invention.

Preferred embodiments of this invention are described herein, includingthe best mode known to the inventors for carrying out the invention.Variations of those preferred embodiments may become apparent to thoseof ordinary skill in the art upon reading the foregoing description. Theinventors expect skilled artisans to employ such variations asappropriate, and the inventors intend for the invention to be practicedotherwise than as specifically described herein. Accordingly, thisinvention includes all modifications and equivalents of the subjectmatter recited in the claims appended hereto as permitted by applicablelaw. Moreover, any combination of the above-described elements in allpossible variations thereof is encompassed by the invention unlessotherwise indicated herein or otherwise clearly contradicted by context.

1-20. (canceled)
 21. A method for processing transactions involving atravel insurer and a travel service provider, comprising: receiving, bya travel insurer computing device, itinerary data in a travel serviceprovider messaging format generated by the travel service provider;converting, by the travel insurer computing device, the itinerary datain the travel service provider messaging format to itinerary data in atravel insurer messaging format based on a mapping of the travel serviceprovider messaging format to the travel insurer messaging format,wherein the mapping is one of a plurality of mappings between messagingformats associated with travel service providers and the travel insurermessaging format; determining, by the travel insurer computing device, atravel insurance policy based on the itinerary data in the travelinsurer messaging format; and transmitting, by the travel insurercomputing device, information pertaining to the determined travelinsurance policy to a customer computing device for presentation to acustomer of the travel service provider.
 22. The method of claim 21,wherein the information pertaining to the determined travel insurancepolicy is presented to the customer on the customer computing device viaa user interface associated with the travel service provider.
 23. Themethod of claim 21, wherein the travel insurer messaging format is amessaging format compatible with a rating and issuance engine of thetravel insurer, and wherein the determining utilizes the rating andissuance engine.
 24. The method of claim 21, wherein the travel serviceprovider messaging format is one of the group consisting of: XML, HTML,and delimited text.
 25. The method of claim 21, further comprising:converting the information pertaining to the determined travel insurancepolicy into a messaging format compatible with the travel serviceprovider before the transmitting.
 26. The method of claim 21, furthercomprising: receiving, from the customer computing device, a customerresponse corresponding to the determined travel insurance policy,wherein the customer response includes payment information; andconverting, by the travel insurer computing device, the customerresponse including payment information into a corresponding travelinsurer messaging format.
 27. The method of claim 21, furthercomprising: selecting an advertisement for presentation to the consumerbased on the itinerary data; and transmitting the selected advertisementor an indication of the selected advertisement to the customer computingdevice for presentation of the selected advertisement to the customer.28. A non-transitory computer-readable medium, part of a travel insurercomputing system, having processor-executable instructions storedthereon for processing transactions involving a travel insurer and atravel service provider, the processor-executable instructions includinginstructions for: receiving itinerary data in a travel service providermessaging format generated by the travel service provider; convertingthe itinerary data in the travel service provider messaging format toitinerary data in a travel insurer messaging format based on a mappingof the travel service provider messaging format to the travel insurermessaging format, wherein the mapping is one of a plurality of mappingsbetween messaging formats associated with travel service providers andthe travel insurer messaging format; determining a travel insurancepolicy based on the itinerary data in the travel insurer messagingformat; and transmitting information pertaining to the determined travelinsurance policy to a customer computing device for presentation to acustomer of the travel service provider.
 29. The non-transitorycomputer-readable medium of claim 28, wherein the information pertainingto the determined travel insurance policy is presented to the customeron the customer computing device via a user interface associated withthe travel service provider.
 30. The non-transitory computer-readablemedium of claim 28, wherein the travel insurer messaging format is amessaging format compatible with a rating and issuance engine of thetravel insurer, and wherein the determining utilizes the rating andissuance engine.
 31. The non-transitory computer-readable medium ofclaim 28, wherein the travel service provider messaging format is one ofthe group consisting of: XML, HTML, and delimited text.
 32. Thenon-transitory computer-readable medium of claim 28, theprocessor-executable instructions further comprising instructions for:converting the information pertaining to the determined travel insurancepolicy into a messaging format compatible with the travel serviceprovider before the transmitting.
 33. The non-transitorycomputer-readable medium of claim 28, the processor-executableinstructions further comprising instructions for: receiving, from thecustomer computing device, a customer response corresponding to thedetermined travel insurance policy, wherein the customer responseincludes payment information; and converting the customer responseincluding payment information into a corresponding travel insurermessaging format.
 34. The non-transitory computer-readable medium ofclaim 28, the processor-executable instructions further comprisinginstructions for: selecting an advertisement for presentation to theconsumer based on the itinerary data; and transmitting the selectedadvertisement or an indication of the selected advertisement to thecustomer computing device for presentation of the selected advertisementto the customer.
 35. A travel insurer computing system for processingtransactions involving a travel insurer and a travel service provider,comprising: a travel insurer server, configured to: receive itinerarydata in a travel service provider messaging format generated by thetravel service provider; convert the itinerary data in the travelservice provider messaging format to itinerary data in a travel insurermessaging format based on a mapping of the travel service providermessaging format to the travel insurer messaging format, wherein themapping is one of a plurality of mappings between messaging formatsassociated with travel service providers and the travel insurermessaging format; determine a travel insurance policy based on theitinerary data in the travel insurer messaging format; and transmitinformation pertaining to the determined travel insurance policy to acustomer computing device for presentation to a customer of the travelservice provider; and a database, configured to store the plurality ofmappings between messaging formats associated with travel serviceproviders and the travel insurer messaging format.
 36. The travelinsurer computing system of claim 35, wherein the travel insurermessaging format is a messaging format compatible with a rating andissuance engine of the travel insurer, and wherein to determine thetravel insurance policy, the travel insurer server is configured toexecute the rating and issuance engine.
 37. The travel insurer computingsystem of claim 35, wherein the travel service provider messaging formatis one of the group consisting of: XML, HTML, and delimited text. 38.The travel insurer computing system of claim 35, wherein the travelinsurer server is further configured to: convert the informationpertaining to the determined travel insurance policy into a messagingformat compatible with the travel service provider before thetransmitting.
 39. The travel insurer computing system of claim 35,wherein the travel insurer server is further configured to: receive,from the customer computing device, a customer response corresponding tothe determined travel insurance policy, wherein the customer responseincludes payment information; and convert the customer responseincluding payment information into a corresponding travel insurermessaging format.
 40. The travel insurer computing system of claim 35,wherein the travel insurer server is further configured to: select anadvertisement for presentation to the consumer based on the itinerarydata; and transmit the selected advertisement or an indication of theselected advertisement to the customer computing device for presentationof the selected advertisement to the customer.